14 research outputs found

    Acute: high-level programming language design for distributed computation

    No full text
    Existing languages provide good support for typeful programming of standalone programs. In a distributed system, however, there may be interaction between multiple instances of many distinct programs, sharing some (but not necessarily all) of their module structure, and with some instances rebuilt with new versions of certain modules as time goes on. In this paper we discuss programming language support for such systems, focussing on their typing and naming issues. We describe an experimental language, Acute, which extends an ML core to support distributed development, deployment, and execution, allowing type-safe interaction between separately-built programs. The main features are: (1) type-safe marshalling of arbitrary values; (2) type names that are generated (freshly and by hashing) to ensure that type equality tests suffice to protect the invariants of abstract types, across the entire distributed system; (3) expression-level names generated to ensure that name equality tests suffice for type-safety of associated values, e.g. values carried on named channels; (4) controlled dynamic rebinding of marshalled values to local resources; and (5) thunkification of threads and mutexes to support computation mobility. These features are a large part of what is needed for typeful distributed programming. They are a relatively lightweight extension of ML, should be efficiently implementable, and are expressive enough to enable a wide variety of distributed infrastructure layers to be written as simple library code above the byte-string network and persistent store APIs. This disentangles the language runtime from communication intricacies. This paper highlights the main design choices in Acute. It is supported by a full language definition (of typing, compilation, and operational semantics), by a prototype implementation, and by example distribution libraries

    Acute: High-level programming language design for distributed computation : Design rationale and language definition

    Get PDF
    This paper studies key issues for distributed programming in high-level languages. We discuss the design space and describe an experimental language, Acute, which we have defined and implemented. Acute extends an OCaml core to support distributed development, deployment, and execution, allowing type-safe interaction between separately-built programs. It is expressive enough to enable a wide variety of distributed infrastructure layers to be written as simple library code above the byte-string network and persistent store APIs, disentangling the language runtime from communication. This requires a synthesis of novel and existing features: (1) type-safe marshalling of values between programs; (2) dynamic loading and controlled rebinding to local resources; (3) modules and abstract types with abstraction boundaries that are respected by interaction; (4) global names, generated either freshly or based on module hashes: at the type level, as runtime names for abstract types; and at the term level, as channel names and other interaction handles; (5) versions and version constraints, integrated with type identity; (6) local concurrency and thread thunkification; and (7) second-order polymorphism with a namecase construct. We deal with the interplay among these features and the core, and develop a semantic definition that tracks abstraction boundaries, global names, and hashes throughout compilation and execution, but which still admits an efficient implementation strategy

    Amino Acid Solutions for 177Lu-Oxodotreotide Premedication: A Tolerance Study

    No full text
    Background: The co-infusion of amino acid solutions during peptide receptor radionuclide therapy reduces the tubular reabsorption of 177Lu-oxodotreotide, thus minimizing nephrotoxicity. In our nuclear medicine department, the patients received two different types of amino acid perfusion over time: a commercial solution (CS) containing 10% amino acids, and a 2.5% lysine–arginine (LysArg) hospital preparation, produced by a referral laboratory. The aim of the present study was to analyze the tolerance of the two amino acid solutions. Methods: The patient files were analyzed and double-checked. The study parameters comprised the gender, age, primary tumor site, type of amino acid perfusion, adverse events (AE) and WHO AE grades, antiemetic premedication, creatinine, and serum potassium level. Results: From February 2016 to February 2019, 76 patients were treated, for a total 235 cycles. AEs occurred in 71% of the CS cycles (n = 82/116), versus 18% (n = 21/119) in the LysArg group (p < 0.0001). In the CS group, the AEs were mostly WHO grade 4 (n = 24/82), and mostly grade 1 in the LysArg group (n = 13/21). Poisson regression showed a higher risk of AE overall and of grades 3 and 4 in the females and with CS. The mean creatinine clearance was identical before and after the PRRT cycles, whichever amino acid perfusion was used. Conclusions: The lysine–arginine preparation showed better tolerance than the commercial solution. The change to LysArg reduced the antiemetic premedication from four molecules to one

    Under consideration for publication in J. Functional Programming 1 Acute: High-level programming language design for distributed computation

    No full text
    † INRIA Rocquencourt Existing languages provide good support for typeful programming of standalone programs. In a distributed system, however, there may be interaction between multiple instances of many distinct programs, sharing some (but not necessarily all) of their module structure, and with some instances rebuilt with new versions of certain modules as time goes on. In this paper we discuss programminglanguage support for such systems, focussing on their typing and naming issues. We describe an experimental language, Acute, which extends an ML core to support distributed development, deployment, and execution, allowing type-safe interaction between separately-built programs. The main features are: (1) type-safe marshalling of arbitrary values; (2) type names that are generated (freshly and by hashing) to ensure that type equality tests suffice to protect the invariants of abstract types, across the entire distributed system; (3) expression-level names generated to ensure that name equality tests suffice for type safety of associated values, e.g. values carried on named channels; (4) controlled dynamic rebinding of marshalled values to local resources; and (5) thunkification of threads and mutexes to support computation mobility

    Abstract Acute: high-level programming language design for distributed computation

    No full text
    This paper studies key issues for distributed programming in high-level languages. We discuss the design space and describe an experimental language, Acute, which we have defined and implemented. Acute extends an OCaml core to support distributed development, deployment, and execution, allowing type-safe interaction between separately-built programs. It is expressive enough to enable a wide variety of distributed infrastructure layers to be written as simple library code above the byte-string network and persistent store APIs, disentangling the language runtime from communication. This requires a synthesis of novel and existing features: (1) type-safe marshalling of values between programs; (2) dynamic loading and controlled rebinding to local resources; (3) modules and abstract types with abstraction boundaries that are respected by interaction; (4) global names, generated either freshly or based on module hashes: at the type level, as runtime names for abstract types; and at the term level, as channel names and other interaction handles; (5) versions and version constraints, integrated with type identity; (6) local concurrency and thread thunkification; and (7) secondorder polymorphism with a namecase construct. We deal with the interplay among these features and the core, and develop a semantic definition that tracks abstraction boundaries, global names, and hashes throughout compilation and execution, but which still admits an efficient implementation.
    corecore